公司為了推進新一代產品，在高層主管的力挺下，導入了敏捷開發。然而，事情沒那麼簡單，因為部分資深工程師依然要兼顧現有的產品，結果可想而知——這些工程師一邊要搞新產品的敏捷衝刺，另一邊還要應對舊產品的功能開發，這樣的「兩頭燒」已經足夠慘烈，更何況這兩個產品的程式語言和框架還是完全不同的！

結果呢？新產品的開發進度還停留在一些基本功能修修補補的階段，完全沒有那種「敏捷速度感」，這可不是我們想看到的敏捷，這簡直就是開發中的慢動作！

但這還沒完，系統分析師那邊也出現了類似的問題，人手不足，還得兼顧不同專案，狀況和開發人員一模一樣。再這樣下去，不僅新產品要掛，連現有產品的維護也岌岌可危。

所以，我決定在下一個衝刺開始前，快刀斬亂麻，找了主管們開會，列出一張A4分析表，清楚說明目前兼職的弊端。結果很明顯，這種分心多用的方式只會拖慢新舊產品的開發進度。我們如果要真正敏捷起來，就必須停止這種「假裝多工」的兼職模式。

調整策略，避免兼職的陷阱

於是，我們果斷調整了團隊的結構，原本有三位資深工程師同時在兩條產品線上作戰，我們決定只留下兩位，其中一位回到現有的產品線，穩住現狀，另一位全力投身新產品開發。再來，再將一位資深系統分析師換成兩位較資淺的分析師，以分擔新產品開發的工作壓力。

這樣做的目的是什麼？不為別的，只為讓團隊中的每一個人都能專注於他們當前的衝刺目標中，專注就是敏捷的關鍵。這樣，衝刺的開發人力才能穩定可預測，才能在敏捷的路上越走越順。

敏捷的價值：專注就是效率

你要知道，敏捷的核心價值之一就是專注。當每個人都全力投入到單一產品線中，衝刺才能更有效率。畢竟，衝刺週期是固定的，目標也是在一開始就設定好的。如果每次都讓一些臨時的插單任務打亂節奏，任務就像從天而降的隕石，砸得團隊手忙腳亂。這時，最好的解決辦法是根據任務的緊急程度和重要性，優先替換掉還沒開始的任務，這樣才能確保每個衝刺的目標都是明確且可以如期完成的。

敏捷開發的成功，靠的可不是「應付突如其來的意外」，而是提前規劃和有效協作。你不可能一邊兼職，一邊還期待著能夠有高效的衝刺結果，那是不現實的，看倌們趕快醒醒吧。

逃出「隕石任務」的轟炸

還記得上一篇文章提過的「好的開發者體驗」吧？其中一個重要因素就是「中斷」。當你的團隊同時兼職不同產品線時，切換不同程式語言和框架的過程就是一場「認知大冒險」，這種中斷完全是魔王級的挑戰。不僅如此，這些中斷還會摧毀開發者的心流，打亂他們的節奏，最後導致開發進度緩慢，甚至衝刺失敗。

所以，回到敏捷的核心價值，保持專注、最小化中斷，才是敏捷成功的基礎。如果你經常受到那些突如其來的隕石任務轟炸，那麼趕緊找到方法避免這種情況吧！